Generating a Relational Database
The examples you have
worked with up to this point have been from a dimensional database that
uses a star or snowflake schema (the CompSales
database). Very often, however, you create cubes based on requirements
only and do not have an existing data source (or sources) to draw on at
design time. After you complete your cube design, you can choose to
generate a relational schema that can be used to retain (that is,
stage) the cube’s source data or that can be a data warehouse/data mart
unto itself. Figure 49 shows the start of the Schema Generation Wizard for building a data warehouse/staging database from the top down.
Note
Designing
dimensional databases is an art form and requires not only sound
dimensional modeling knowledge, but also knowledge of the business
processes with which you are dealing. Data warehousing has several
design approaches. Regardless of which approach you take, having a good
understanding of the approach’s design techniques is critical to the
success of a data warehouse project. Although Microsoft provides a
powerful set of tools to implement data marts, astute execution of
design methods is critical to getting the correct data—the truly
business-significant business data—to the end users.
Limitations of a Relational Database
Even using a tool such as
SSAS, you face limitations when dealing with a normalized database.
Using a view can often solve (or mask) these issues. In some cases,
however, more complicated facts and dimensions might require
denormalized tables or a dimensional database in the storage component
of the data warehouse to bring information together. Data cleansing and
transformation are also major considerations before you attempt to
present decision makers with data from OLTP systems.
